1. Field of the Invention
The present invention relates to a process for assisting in the administration of a distributed application based on a binary configuration file in a computer system. This process for assisting in the administration can especially be applied to a transaction processing manager like the one marketed under the name “Tuxedo.”
2. Description of Related Art
The “Tuxedo” application allows different software programs that do not recognize one another, but that use a certain protocol, to work together.
Generally, the “Tuxedo” application is a distributed application, i.e., an application that runs on several machines at the same time. A “machine” is the node of the network in which the servers of the “Tuxedo” application run, and the “master machine” is the one that controls the “Tuxedo” application. FIG. 8 illustrates the operation of the “Tuxedo” application. When the “Tuxedo” application is started up, the binary configuration file (TUXCONFIG) is loaded from the disk in the bulletin board (BB) of the master machine (Mm). The bulletin board (BB) represents a set of data structures located in the shared memory and containing information on the transactions, the servers, the services and the clients belonging to the “Tuxedo” application. During the startup of the master machine (Mm), the bulletin board (BB) is loaded into the memory of the master machine (Mm) from a binary “Tuxedo” configuration file (TUXCONFIG). Then, it is distributed to the slave machines (Me) by the master process of the application, called the distinguished bulletin board liaison (DBBL). Each machine of the application is under the control of a process called a bulletin board liaison (BBL). The distinguished bulletin board liaison DBBL is an administrative process that communicates with the bulletin board liaison (BBL) processes ordinate the updates of the bulletin board (BB). The bulletin board liaison BBL is an administrative process that is responsible for maintaining an updated copy of the bulletin board (BB) in its own slave machine (Me). Each slave machine (Me) is under the control of a bulletin board liaison process BBL, implicitly defined by “Tuxedo.”
The bridge (BRIDGE) (1) is a process for managing communications between the servers of the “Tuxedo” application. Each machine is provided with a bridge implicitly defined by “Tuxedo.” The server TMS (Transaction Manager Server) is a process that manages a validation protocol and recovery for transactions executed by several application servers. The listener module (tlisten, 3) is a process that manages the messages intended for the “Tuxedo” application in a given machine before the bridge process (BRIDGE) of this machine has been started. A listener module allows a machine to receive information coming from other machines. A listener module is required in each machine when the application is distributed.
The “Tuxedo” application is created by the construction of a binary configuration file that defines the architecture of said application (FIG. 7). During the creation of the configuration file, an administrator defines the services (Se) provided by the application and assigns them to application servers (Sr). The administrator then defines groups (G) and assigns a set of servers (Sr). Finally, the administrator assigns groups (G) to a machine (M). Each application must be given a minimum of one group (G), one service (Se) and one server (Sr). A machine (M) can manage several groups (G).
After the creation of a “Tuxedo” application, this application must be administered. The object of the invention is to create a system to assist in the administration of the “Tuxedo” application. The main steps involved in the administration of a “Tuxedo” application consist of:
a step for loading the binary configuration file of the “Tuxedo” application;
a step for starting listener modules when the “Tuxedo” application is a distributed application;
a step for starting the Tuxedo application;
a step for controlling the application. This consists of displaying information and, if necessary, performing the required corrections;
a step for stopping the application; and possibly
a step for stopping the listener modules when they have been started.
The administration of a distributed application can quickly become very complex. In fact, before this administration can begin, the operator must activate a listener module in each slave machine on which he wishes to act. To do this, the administrator must first consult a file containing information on the activation of the listener modules. This file is generally stored, in a place that must be remembered, in each machine. Then, with the aid of this information, the operator must activate the listener module of each machine, one by one. Thus, if the application involves ten machines, the operator must activate the listener module in each of the ten machines, then at the end of the application, deactivate the ten listener modules. This repetitive operation is long and tedious.
Each administrator has his own solution for performing these tasks. The most common solution is to store in each machine, in a place that must be remembered, scripts for activating the listener modules, and to keep a paper copy of the configuration file. The administrator must make sure that the information is up to date at all times. Each time the configuration changes, he must not forget to print out a paper copy of the configuration file and update the scripts in the slave machines.
Moreover, each time the operator wants to act on an element of an application, he must be able to quickly and accurately identify a given resource, such as for example, when stopping the server “serve1”, belonging to the group “group1” in the machine “mach1”.
When the number of applications increases, these manual operations are the source of numerous errors.